You don't need to spell these out. Please remove them.

ACK

This is invalid syntax. What are you trying to describe here?

I'm trying to describe that a tag has this syntax .<charaters>[.<characters|.....]

ie: .Foo.bar.bar

But this conversation might be moot based on the output of https://github.com/swiftlang/swift-evolution/pull/3040/files#r2607028858

We should think about whether the leading period should be encoded in the JSON. Since this schema may be used by other libraries that don't use Swift's dot syntax, my gut says they shouldn't be encoded and we should just define <tag> ::= <string>.

We should think about whether the leading period should be encoded in the JSON

I don't have a strong opinion here.

I agree w/ @grynspan and think we shouldn't necessarily specify in the schema itself that there will always be a leading period character. But I do think the proposal should clearly specify whether, in the encoded string, the leading period and any subsequent punctuation will be preserved as it was written in source. The main thing I'm trying to convey is that we ought to clearly define the behavior, whatever it is.

And on this specific point, I would suggest you define the behavior such that it will precisely preserve the way the tag was spelled in source. So if the code had .tags(.blue) the string would be ".blue". If it had .tags(Tag.red), the string would be "Tag.red", and so on. The latter example differs from the example you show in the current proposal, so that represents a change.

That would be the wrong abstraction though, as it would mean Tag.red and .red don't compare equal. (I don't think that string is available at runtime anyway!) Furthermore, preserving the source would prevent the use of this feature with libraries that define tags using different syntax. For example, C++ might have something using ::, or Objective-C might just use @"red".

I'd like to just define it formally as <string> and document that Swift Testing specifically normalizes to "red" since that would be most compatible with what other libraries or tagging syntaxes would reasonably do.

I'm open to that. To be comprehensive about this, how would examples which include interstitial punctuation, like .tags(.NestedType.bar, .NestedType.AnotherNestedType.baz) be encoded in the JSON? As "NestedType.bar" and "NestedType.AnotherNestedType.baz", respectively, or something else?

In effect, this will mean we'll be treating the optional (Testing.)Tag type namespace prefixes as "special", and stripping them when present, along with the leading period. Which is fine, but it should be spelled out in the proposal. (Maybe it would be helpful to include a Markdown table with several of these examples.)

I agree with @grynspan that Tag.red and .red should be represented the same way in the event stream. Do we want to consider having the JSON represents each tags as an array, or maybe an object, instead of string? This might allow some IDE's to represent a tree structure of all tags?

I'm in favor of the proposal's current behavior for the two examples it shows—that .tags(.blue) and .tags(Tag.red) are represented as ".blue" and ".red", respectively.

Can we include one more example, just to clarify the handling of nested tags? Specifically, can we document that a two-level tag like .tags(.Foo.bar) would map to the string ".Foo.bar"?

Actually, hold on. More investigation has revealed an interesting data point: the sourcekit-lsp indexer currently does not include the leading period, so that suggests omitting it in the JSON event stream representation would make things align better and ultimately, that's one of the biggest considerations.

So here's my current preference:

I'm happy to use a string with the leading . removed. Do we know where sourcekit-lsp indexer gets the value from? Does it generate that string itself? Is there value in creating a Swift Testing API that would be the source of truth, which sourcekit-lsp can then eventually start using?

That's conceivable, but pretty far outside the scope of this proposal so I'd recommend breaking that out into a separate discussion

FYI these three aren't valid. Use .minutes() instead (the overloads that take Swift.Duration are unavailable.)

Nitpick: missing the "version" field.

The compiler will reject an invalid URL string here rather than interpreting it as a comment.

If we're escaping forward slashes right now, that's a bug on our side I think.

I don't think this sentence is meaningful.

I'd suggest reworking this section. The leading sentence doesn't say anything and then bullet points are vague and promise functionality that's beyond the scope of this proposal. Perhaps something like:

"Supporting tools like IDEs and CI systems consume the JSON event stream and will be able to use this new information to provide richer developer experiences. For example, an IDE could allow developers to sort the content of a test report by tag, or could highlight failing tests with associated bugs that are incorrectly marked fixed."

(But feel free to rewrite that of course, that's just off the top of my head.)

We can probably drop this section as the "migration path" isn't very long. Or just rewrite it to something like "tools that request this version of the JSON event stream schema will automatically have access to the new fields."

This is the problem statement, not the solution.